Network Working Group F. Baker 
Request for Comments: 4923 Cisco Systems 


Category: Informational P. Bose 
Lockheed Martin 


August 2007 


Quality of Service (QoS) Signaling in a Nested Virtual Private Network 


Status of This Memo 


This memo provides information for the Internet community. It does 
not specify an Internet standard of any kind. Distribution of this 
memo is unlimited. 


Copyright Notice 
Copyright (C) The IETF Trust (2007). 


Abstract 


Some networks require communication between an interior and exterior 
portion of a Virtual Private Network (VPN) or through a concatenation 
of such networks resulting in a nested VPN, but have sensitivities 
about what information is communicated across the boundary, 
especially while providing quality of service to communications with 
different precedence. This note seeks to outline the issues and the 
nature of the proposed solutions based on the framework for 
Integrated Services operation over Diffserv networks as described in 


RFC 2998. 
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1. Introduction 
1.1. Problem Statement 


More and more networks wish to guarantee secure transmission of IP 
traffic across public LANs or WANs and therefore use Virtual Private 
Networks. Some networks require communication between an interior 
and exterior portion of a VPN or through a concatenation of such 
networks resulting in a nested VPN, but have sensitivities about what 
information is communicated across the boundary, especially while 
providing quality of service to communications with different 
precedence. This note seeks to outline the issues and the nature of 
the proposed solutions. The outline of the QoS solution for real- 
time traffic has been described at a high level in [RFC4542]. The 
key characteristics of this proposal are that 


o it uses standardized protocols, 


o it includes reservation setup and teardown for guaranteed and 
controlled load services using the standardized protocols, 


o it is independent of link delay, and therefore consistent with 
high delay*bandwidth networks as well as the more common variety, 


o it has no single point of failure, such as a central reservation 
manager, 


o it provides for the preemption of established data flows, 


o in that preemption, it not only permits a policy-admitted data 
flow in, but selects a specific data flow to exclude based upon 
control input rather than simply accepting a loss of service 
dictated at the discretion of the network control function, and 


o it interoperates directly with SIP Proxies, H.323 Gatekeepers, or 
other call management subsystems to present the other services 
required in a preemptive or preferential telephone network. 


The thrust of the memo surrounds VPNs that use encryption in some 
form, such as IPsec and their subsequent nesting across multiple 
network domains. This specific type of VPNs is further clarified in 
Section 1.3, which describes the nested VPN as an example of an IPsec 
or IPsec like VPN under the context of a ’customer provisioned’ VPN. 
As a result, we will discuss the VPN router supporting "plaintext" 
and "ciphertext" interfaces. However, the concept extends readily to 
any form of aggregation, including the concept proposed in [RFC3175] 
of the IP traffic entering and leaving a network at identified 
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points, and the use of other kinds of tunnels including Generic 
Routing Encapsulation (GRE), IP/IP, MPLS, and so on. 


1.2. Background Information and Terminology 


A note on the use of the words "priority" and "precedence" in this 
document is in order. The term "priority" has been used in this 
context with a variety of meanings, resulting in a great deal of 
confusion. The term "priority" is used in this document to identify 
one of several possible datagram scheduling algorithms. A scheduler 
is used when deciding which datagram will be sent next on a computer 
interface; a priority scheduler always chooses a datagram from the 
highest priority class (queue) that is occupied, shielding one class 
of traffic from most of the jitter by passing jitter it would 


otherwise have experienced to another class. [RFC3181] applies the 
term to a reservation, in a sense that this document will refer to as 
"precedence". The term "precedence" is used in the sense implied in 


the phrase "Multi-Level Precedence and Preemption" [ITU.MLPP.1990]; 
some classes of sessions take precedence over others, which may 
result in bandwidth being admitted that might not otherwise have been 
or may result in the prejudicial termination of a lower-precedence 


session under a stated set of circumstances. For the purposes of the 
present discussion, "priority" is a set of algorithms applied to 
datagrams, where "precedence" is a policy attribute of sessions. The 


techniques of priority comparisons are used in a router or a policy 
decision point to implement precedence, but they are not the same 
thing. 


Along the same lines, it is important for the reader to understand 
the difference between QoS policies and policies based on the 
"precedence" or "importance" of data to the person or function using 
it. Voice, regardless of the precedence level of the call, is 
impeded by high levels of variation in network-induced delay. As a 
result, voice is often serviced using a priority queue, transferring 
jitter from that application's traffic to other applications. This 
is as true of voice for routine calls as it is for flash traffic. 
There are classes of application traffic that require bounded delay. 
That is a different concept than "no jitter"; they can accept jitter 
within stated bounds. Routing protocols such as OSPF or BGP are 
critical to the correct functioning of network infrastructure. While 
they are designed to work well with moderate loss levels, they are 
not helped by them, and even a short period of high loss can result 
in dramatic network events. Variation in delay, however, is not at 
all an issue if it is within reasonable bounds. As a result, it is 
common for routers to treat routing protocol datagrams in a way that 
limits the probability of loss, accepting relatively high delay in 
some cases, even though the traffic is absolutely critical to the 
network. Telephone call setup exchanges have this characteristic as 
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well: faced with a choice between loss and delay, protocols like SIP 
and H.323 far prefer the latter, as the call setup time is far less 
than it would be if datagrams had to be retransmitted, and this is 
true regardless of whether the call is routine or of high precedence. 
As such, QoS markings tell us how to provide good service to an 
application independent of how "important" it may be at the current 
time, while "importance" can be conveyed separately in many cases. 


1.3. Nested VPNs 
One could describe a nested VPN network in terms of three network 
diagrams. Figure 1 shows a simple network stretched across a VPN 
connection. The VPN router (where, following [RFC2460], a "router" 
is "a node that forwards packets not explicitly addressed to 
itself"), performs the following steps: 


o receives an IP datagram from a plaintext interface, 


o determines what remote enclave and therefore other VPN router to 
forward it to, 


o ensures that it has a tunnel mode security association (as 
generally defined in [RFC4301], Section 4) with that router, 


o encloses the encrypted datagram within another VPN (e.g., IPsec) 
and IP header, and 


o forwards the encapsulated datagram toward the remote VPN router. 
The receiving VPN router reverses the steps: 


o determines what security association the datagram was received 
from, 


o decrypts the interior datagram, 
o forwards the now-decapsulated datagram on a plaintext interface. 


The use of IPsec in this manner is described as the tunnel mode of 
[RFC4301] and [RFC4303]. 
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Host Host Host Host Host Host 


VPN-Router 


| | IPsec Tunnel through routed network 


VPN-Router 


Host Host Host Host Host Host 
Figure 1: VPN-Connected Enclave 


An important point to understand is that the VPN tunnel, like other 
features of the routed network, are invisible to the host. The host 
Can infer that "something out there" is affecting the Path MTU, 
introducing delay, or otherwise affecting its data stream, but if 
properly implemented, it should be able to adapt to these. The words 
"if properly implemented" are the bane of every network manager, 
however; substandard implementations do demonstrably exist. 


Outside of the enclave, the hosts are essentially invisible. The 
communicating enclaves look like a simple data exchange between peer 
hosts across a routed network, as shown in Figure 2. 


Hosts Not Visible 


Router 


VPN-Router 


VPN-Router 


Router 
/ / 
Hosts Not Visible 


Figure 2: VPN-Connected Enclave from Exterior Perspective 


Such networks can be nested and re-used in a complex manner. As 
shown in Figure 3, a pair of enclaves might communicate across a 
ciphertext network that, for various reasons, is itself re-encrypted 
and transmitted across a larger ciphertext network. The reasons for 
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doing this vary, but they relate to information-hiding in the wider 
network, different levels of security required for different enclosed 
enclaves, and so on. 


Host Host Host Host Host Host 
/------------------ fo /=------------------ / 
Router ------- Router 
VPN-Router VPN-Router VPN-Router 
/--------------------- fo /=---------- / 
ROUtet. =========55> Router 
VPN-Router VPN-Router 
/----------- fo /---------- / 
Router ------- Router 
Router ------- Router 
/----------- [0 /---------- / 
VPN-Router VPN-Router 
ROUTEY  ====2==2==5=25 Router 
| ee tt ane / 
VPN-Router VPN-Router VPN-Router 
Router ------- Router 
/------------------ fo /=------------------ / 
Host Host Host Host Host Host 


Figure 3: Nested VPN 


The key question this document explores is "how do reservations, and 
preemption of reservations, work in such an environment?" 


1.4. Signaled QoS Technology 


The Integrated Services model for networking was originally proposed 
in [RFC1633]. In short, it divides all applications into two broad 
classes: those that will adapt themselves to any available bandwidth, 
and those that will not or cannot. In the words of [RFC1633]: 


One class of applications needs the data in each packet by a 
certain time and, if the data has not arrived by then, the data 
is essentially worthless; we call these "real-time" 
applications. Another class of applications will always wait 
for data to arrive; we call these "elastic" applications. 
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The Integrated Services model defines data flows supporting 
applications as either "real-time" or "elastic". It should be noted 
that "real-time" traffic is also referred to as "inelastic" traffic, 
and that elastic traffic is occasionally referred to as "non-real- 
time". 


In this view, the key issue is the so-called "playback point": a 
real-time application is considered to have a certain point in time 
at which data describing the next sound, picture, or whatever to be 
delivered to a display device or forfeit its utility, while an 
elastic application has no such boundary. Another way to look at the 
difference is that real-time applications have an irreducible lower 
bound on their bandwidth requirements. For example, the typical 
G.711 payload is delivered in 160-byte samples (plus 40 bytes of IP/ 
UDP/RTP headers) at 20 millisecond intervals. This will yield 80 
kbps of bandwidth, without silence suppression, and not accounting 
for the layer 2 overhead. To operate in real-time, a G.711 codec 
requires the network over which its data will be delivered to support 
communications at 80 kbps at the IP layer with roughly constant end- 
to-end delay and nominal or no loss. If this is not possible (if 
there is significant loss or wide variations in delay), voice quality 
will suffer. On the other hand, if many megabits of capacity are 
available, the G.711 codec will not increase its bandwidth 
requirements either. Although adaptive codecs exist (e.g., G.722.2 
or G.726), the adaptive mechanism can either require greater or 
lesser bandwidth and can adapt only within a certain range of 
bandwidth requirements beyond which the quality of the data flow 
required is not met. Elastic applications, however, will generally 
adapt themselves to any network: if the bottleneck provides 9600 bits 
per second, a Web transfer or electronic mail exchange will happen at 
9600 bits per second, and if hundreds of megabits are available, the 
TCP (or SCTP) transport will increase their transfer rate in an 
attempt to reduce the time required to accomplish the transfer. 


For real-time applications, those that require data to be delivered 
end to end with at least a certain rate and with delays varying 
between stated bounds, the Integrated Services architecture proposes 
the use of a signaling protocol that allows the communicating 
applications and the network to communicate about the application 
requirements and the network’s capability to deliver them. Several 
such protocols have been developed or are under development, notably 
including the Resource Reservation Protocol (RSVP) and Next Steps in 
Signaling (NSIS). The present discussion is limited to RSVP, 
although any protocol that delivers a similar set of capabilities 
could be considered. 
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1.5. The Resource Reservation Protocol (RSVP) 


RSVP is initially defined in [RFC2205] with a set of datagram 
processing rules defined in [RFC2209] and datagram details for 
Integrated Services [RFC2210]. Conceptually, this protocol specifies 
a way to identify data flows from a source application to a 
destination application and request specific resources for them. The 
source may be a single machine or a set of machines listed explicitly 
or implied, whereas the destination may be a single machine or a 
multicast group (and therefore all of the machines in it). Each 
application is specified by a transport protocol number in the IP 
protocol field, or may additionally include destination and perhaps 
source port numbers. The protocol is defined for both IPv4 [RFC0791] 
and IPv6 [RFC2460]. It was recognized immediately that it was also 
necessary to provide a means to perform the same function for various 
kinds of tunnels, which implies a relationship between what is inside 


and what is outside the tunnel. Definitions were therefore developed 
for IPsec [RFC2207] and [RFC4860] and for more generic forms of 
tunnels [RFC2746]. With the later development of the Differentiated 


Services Architecture [RFC2475], definitions were added to specify 
the Differentiated Services Code Point (DSCP) [RFC2474] to be used by 
a standard RSVP data flow in [RFC2996] and to use a pair of IP 
addresses and a DSCP as the identifying information for a data flow 
[RFC3175]. 


In addition, the initial definition of the protocol included a 
placeholder for policy information, and for preemption of 
reservations. This placeholder was later specified in detail in 
[RFC2750] with a view to associating a policy [RFC2872] with an 
identity [RFC3182] and thereby enabling the network to provide a 
contracted service to an authenticated and authorized user. This was 
integrated with the Session Initiation Protocol [RFC3261] in 
[RFC3312]. Preemption of a reservation is specified as in [RFC3181] 
-- a reservation that is installed in the network using an Preemption 
Priority and retained using a separate Defending Priority may be 
removed by the network via an RESV Error signal that removes the 
entire reservation. This has issues, however, in that the matter is 
often not quite so black and white. If the issue is that an existing 
reservation for 80 kbps can no longer be sustained but a 60 kbps 
reservation could, it is possible that a VoIP sender could change 


from a G.711 codec to a G.729 codec and achieve that. Or, if there 
are multiple sessions in a tunnel or other aggregate, one of the 
calls could be eliminated leaving capacity for the others. [RFC4495] 


seeks to address this issue. 


In a similar way, a capability was added to limit the possibility of 
control signals being spoofed or otherwise attacked [RFC2747] 
[RFC3097]. 
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[RFC3175] describes several features that are unusual in RSVP, being 
specifically set up to handle aggregates in a service provider 
network. It describes three key components: 


o The RFC 3175 session object, which identifies not the IP addresses 
of the packets that are identified, but the IP addresses of the 
ingress and egress devices in the network, and the DSCP that the 
traffic will use. 


o The function of a reservation "aggregator", which operates in the 
ingress router and accepts individual reservations from the 
"customer" network. It aggregates the reservations into the ISP 
core in a tunnel or an MPLS LSP, or as a traffic stream that is 
known to leave at the deaggregator. 


o The function of a reservation "deaggregator", which operates in 
the egress router and breaks the aggregate reservation and data 
streams back out into individual data streams that may be passed 
to other networks. 


In retrospect, the Session Object specified by RFC 3175 is useful but 
not intrinsically necessary. If the ISP network uses tunnels, such 
as MPLS LSPs, IP/IP or GRE tunnels or enclosing IPsec Security 
Associations, the concepts of an aggregator and a deaggregator work 
in the same manner, although the reservation mechanism would be that 
of [RFC3473] and [RFC3474], [RFC2207], [RFC4860], or [RFC2746]. 


1.6. Logical Structure of a VPN Router 


The conceptual structure of a VPN router is similar to that of any 
other router. In its simplest form, it is physically a two or more 
port device (similar to that shown in Figure 4), which has one or 
more interfaces to the protected enclave(s) and one or more 
interfaces to the outside world. On the latter, it structures some 
number of tunnels (in the case of an IPsec tunnel, having security 
associations) that it can treat as point-to-point interfaces froma 
routing perspective. 
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+--------- +  +------- +  +----+----+ Ho + 
| RSVP | |Routing| | Net Guara] | IPsec Mgr| 
+----+----+ +---+---+  +----+----+ +----+----+ 
| 
a ee ee ae les 
| IP | 
Ho +-------------------- Ho +------ + 
| 
| +----- +----- + a == + 
| Encrypt/ | | Encrypt/ | 
| |Decrypt for| |Decrypt for| 
| | Security | | Security | 
| |Association| |Association| 
| +----- 4===-- + +----+------ + 
+----------- l ------------ + +---—- : oo l ------ + 
| Plaintext | | Ciphertext | 
| Interface | | Interface | 
Ho + $------------------------- + 


Figure 4: Logical Structure of a VPN Router 


The encrypt/decrypt unit may be implemented as a function of the 
plaintext router, as a function on its interface card, or as a 
function of an external device with a private interface to the IP 
routing functionality of the plaintext router. These are 
conceptually equivalent, although there are practical differences in 
implementation. The key issue is that when IP routing presents a 
message to the encrypt/decrypt unit for transmission, it must also be 
presented with the IP address of the plaintext routing peer, whether 
host or router, to which the security association must be 
established. This IP Address is used to select (and perhaps create) 
the security association, and in turn select the appropriate set of 
security parameters. This could also be implemented by presenting 
the local Security Parameter Index (SPI) for the data, if it has been 
created out of band by the Network Management Process. 


In addition, it is necessary for aggregated signaling to be generated 
for the ciphertext domain. This may be accomplished in several ways: 


o by having the RSVP process on the plaintext router generate the 
messages and having the encrypt/decrypt unit bypass them into the 
ciphertext network 


o by having the plaintext RSVP process advise a process in the 
encrypt/decrypt implementation of what needs to be generated using 
some local exchange, and having it generate such messages, or 
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by having a separate parallel network management system 
intermediate between the plaintext and ciphertext routers, in 
which case, the encrypt/decrypt unit and the parallel network 
system must use the same address, and the ciphertext router must 
distinguish between traffic for them based on SPI or the presence 
of encryption. 


Control plane signaling using this additional path is described in 
Section 3.2. The information flow between the plaintext and 
ciphertext domains includes 


o 


o 


IP datagrams via the encrypt/decrypt unit, 
RSVP signaling via the bypass path, 
Control information coordinating security associations, and 


precious little else. 
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2. Reservation and Preemption in a Nested VPN 
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Figure 5: Reservations in a Nested VPN 


Let us discuss how a resource reservation protocol, 
might be used in a nested virtual private network. 
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2.1. Reservation in a Nested VPN 


A reservation in a nested VPN is very much like a reservation in any 
other network, with one exception: it is composed of multiple 
reservations that must be coordinated. These include a reservation 
within the originating and receiving enclaves and a reservation at 
each layer of the VPN, as shown in Figure 5. 


Thus, when a host in one enclave opens a reservation to a host in 
another enclave, a reservation of the appropriate type and size is 
created end to end. As it traverses the VPN router leaving its 
enclave, the reservation information and the data are placed within 
the appropriate tunnel (e.g., the IPsec Security Association for its 
precedence level to the appropriate remote VPN router). At the 
remote VPN router, it is extracted from the tunnel and passed on its 
way to the target system. The data in the enclave will be marked 
with a DSCP appropriate to its application and (if there is a 
difference) precedence level, and the signaling datagrams (PATH and 
RESV) are marked with a DCLASS object indicating that value. RSVP 
signaling datagrams (PATH and RESV) are marked with a DCLASS object 
indicating the value used for the corresponding data. The DSCP on 
the signaling datagrams, however, is a DSCP for signaling, and has 
the one provision that if routing varies by DSCP, then it must be a 
DSCP that is routed the same way as the relevant data. The [RFC2872] 
policy object specifies the applicable policy (e.g., "routine service 
for voice traffic") and asserts a [RFC3182] credential indicating its 
user (which may be a person or a class of persons). As specified in 
[RFC3181], it also specifies its Preemption Priority and its 
Defending Priority; these enable the Preemption Priority of a new 
session to be compared with the Defending Priority of previously 
admitted sessions. 


On the ciphertext side of the VPN router, no guarantees result unless 
the VPN router likewise sets up a reservation to the peer VPN Router 
across the ciphertext domain. Thus, the VPN router sets up an 
[RFC2207], [RFC4860], or [RFC3175] reservation to its peer. 


The Session Object defined by [RFC2207] or [RFC4860] contains a field 
called a "virtual destination port", which allows the multiplexing of 
many reservations over a common security association and, in the 
latter case, a common DSCP value. Thus, the voice traffic at every 
precedence level might use the Expedited Forwarding (EF) DSCP and 
service as described in [RFC3246], but the reservations would be for 
"the aggregate of voice sessions at precedence Pn between these VPN 
routers". This would allow the network administration to describe 
policies with multiple thresholds, such as "a new session at 
precedence Pn may be accepted if the total reserved bandwidth does 
not exceed threshold Qn; if it is necessary and sufficient to accept 
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the reservation, existing reservations at lower precedences may be 
preemptively reduced to make acceptance of the new session possible". 


In the [RFC3175] case, since the DSCP must be used to identify both 
the reservation and the corresponding data stream, the aggregate 
reservations for different precedence levels require different DSCP 
values. 


In either case, the fundamental necessity is for one VPN router to 
act as what [RFC3175] calls the "aggregator" and another to act as 
the "deaggregator", and extend a VPN tunnel between them. If the VPN 
Tunnel is an IPsec Security Association between the VPN routers and 
the IP packet is entirely contained within (such as is used to cross 
a firewall), then the behavior of [RFC2746] is required of the 
tunnel. That bearer will have the following characteristics: 


o it will have a DSCP corollary to the DSCP for the data or the same 
DSCP as the data it carries, 


o the reservations and data will be carried in security associations 
between the VPN routers, and 


o the specification for the reservation for the tunnel itself will 
not be less than the sum of the requirements of the aggregated 
reservations. 


The following requirements relationships apply between the set of 
enclosed reservations and the tunnel reservation: 


o The sum of the average rates of the contained reservations, having 
been adjusted for the additional IP headers, will be less than or 
equal to the average rate of the tunnel reservation. 


o The sum of the peak rates of the contained reservations, having 
been adjusted for the additional IP headers, will be less than or 
equal to the peak rate of the tunnel reservation. 


o The sum of the burst sizes of the contained reservations, having 
been adjusted for the additional IP headers, will be less than or 
equal to the burst size of the tunnel reservation. 


o The Preemption Priority of a tunnel reservation is identical to 
that of the individual reservations it aggregates. 


o The Defending Priority of a tunnel reservation is identical to 
that of the individual reservations it aggregates. 
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This would differ only in the case that measurement-based admission 
is in use in the tunnel but not in the end system. In that case, the 
tunnel's average bandwidth specification would be greater than or 
equal to the actual average offered traffic. Such systems are beyond 
the scope of this specification. 


As a policy matter, it may be useful to note a quirk in the way 
Internet QoS works. If the policies for various precedence levels 
specify different thresholds (e.g., "to accept a new routine call, 
the total reserved bandwidth after admission may not exceed X; to 
accept a call with a higher precedence level, the total reserved 
bandwidth after admission may not exceed X+Y, and this may be 
achieved by preempting a call with a lower precedence level"), the 
bandwidth Y effectively comes from the bandwidth in use by elastic 
traffic rather than forcing a preemption event. 


2.2. Preemption in a Nested VPN 


As discussed in Section 1.5, preemption is specified in [RFC3181] and 
further addressed in [RFC4495]. The issue is that in many cases the 
need is to reduce the bandwidth of a reservation due to a change in 
the network, not simply to remove the reservation. In the case of an 
end-system-originated reservation, the end system might be able to 
accommodate the need through a change of codec; in the case of an 
aggregate of some kind, it could reduce the bandwidth it is sending 
by dropping one or more reservations entirely. 


In a nested VPN or other kind of aggregated reservation, this means 
that the deaggregator (the VPN router initiating the RESV signal for 
the tunnel) must 

o receive the RESV Error signaling it to reduce its bandwidth, 


o re-issue its RESV accordingly, 


o identify one or more of its aggregated reservations, enough to do 
the job, and 


o signal them to reduce their bandwidth accordingly. 
It is possible, of course, that it is signaling them to reduce their 


bandwidth to zero, which is functionally equivalent to removing the 
reservation as described in [RFC3181]. 


In the routers in the core, an additional case arises. One could 
imagine that some enclave presents the VPN with a single session, and 
that session has a higher precedence level. If some interior link is 


congested (e.g., the reserved bandwidth will exceed policy if the 
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call is admitted), a session between a different pair of VPN routers 
must be preempted. More generally, in selecting a reservation to 
preempt, the core router must always select a reservation at the 
lowest available Defending Priority. This is the reason that various 
precedence levels must be kept separate in the core. 


2.3. Working through an Example 


The network in Figure 5 shows three security layers: six plaintext 
enclaves around the periphery, two ciphertext domains connecting them 
at one layer (referred to in the diagram as an "interface domain"), 
and a third ciphertext domain connecting the first two (referred to 
in the diagram as an "inner domain"). The following distribution of 
information exists: 


o Each enclave has access to general routing information concerning 
other enclaves it is authorized to communicate with: systems in it 
can translate a DNS name for a remote host or domain and obtain 
the corresponding address or prefix. 


o Each enclave router also has specific routing information 
regarding its own enclave. 


o A default route is distributed within the enclave, pointing to its 
VPN router. 


o VPN Routers 1-6 are able to translate remote enclave prefixes to 
the appropriate remote enclave’s VPN router addresses. 


o Each interface domain has access to general routing information 
concerning the other interface domains, but not the enclaves. 
Systems in an interface domain can translate a DNS name for a 
remote interface domain and obtain the corresponding address or 
prefix. 


o Each interface domain router also has specific routing information 
regarding its own interface domain. 


o A default route is distributed within the interface domain, 
pointing to the "inner" VPN router. 


o VPN Routers 7 and 8 are able to translate remote interface domain 
prefixes to remote VPN router addresses. 


o Routers in the inner domain have routing information for that 
domain only. 
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While the example shows three levels, there is nothing magic about 
the number three. The model can be extended to any number of 
concentric layers. 


Note that this example places unidirectional reservations in the 
forward direction. In voice and video applications, one generally 
has a reservation in each direction. The reverse direction is not 
discussed, for the sake of clarity, but operates in the same way in 
the reverse direction and uses the same security associations. 


2.3.1. Initial Routine Reservations - Generating Network State 


Now let us install a set of reservations from H1 to H4, H2 to H5, and 
H3 to H6, and for the sake of argument, let us presume that these are 
at the "routine" precedence. H1, H2, and H3 each initiate a PATH 
signal describing their traffic. For the sake of argument, let us 
presume that H1’s reservation is for an [RFC2205] session, H2’s 
reservation is for a session encrypted using IPsec, and therefore 
depends on [RFC2207], and H3 (which is a Public Switched Telephone 
Network (PSTN) gateway) sends an [RFC3175] reservation comprising a 
number of distinct sessions. Since these are going to H4, H5, and 
H6, respectively, the default route leads them to VPN1, VPN2, and 
VPN3, respectively. 


The VPN routers each ensure that they have an appropriate security 
association or tunnel open to the indicated remote VPN router (VPN4, 
VPN5, or VPN6). This will be a security association or tunnel for 
the indicated application at the indicated precedence level. Having 
accomplished that, it will place the PATH signal into the security 
association and forward it. If such does not already exist, 
following [RFC3175]’s aggregation model, it will now open a 
reservation (send a PATH signal) for the tunnel/SA within the 
interface domain; if the reservation does exist, the VPN router will 
increase the bandwidth indicated in the ADSPEC appropriately. In 
this example, these tunnel/SA reservations will follow the default 
route to VPN7. 


VPN7 ensures that it has an appropriate security association or 
tunnel open to VPN8. This will be a security association or tunnel 
for the indicated application at the indicated precedence level. 
Having accomplished that, it will place the PATH signal into the 
security association and forward it. If such does not already exist, 
following [RFC3175]’s aggregation model, it will now open a 
reservation (send a PATH signal) for the tunnel/SA within the 
interface domain; if the reservation does exist, the VPN router will 
increase the bandwidth indicated in the ADSPEC appropriately. In 
this example, this tunnel/SA reservation is forwarded to VPN8. 
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VPN8 acts as an [RFC3175] deaggregator for the inner domain. This 
means that it receives the PATH signal for the inner domain 
reservation and stores state, decrypts the data stream from VPN7, 
operates on the RSVP signals as an RSVP-configured router, and 
forwards the received IP datagrams (including the updated PATH 
signals) into its interface domain. The PATH signals originated by 
VPN1, VPN2, and VPN3 are therefore forwarded towards VPN4, VPN5, and 
VPN6 according to the routing of the interface domain. 


VPN4, VPN5, and VPN6 each act as an [RFC3175] deaggregator for the 
interface domain. This means that it receives the PATH signal for 
the interface domain reservation and stores state, decrypts the data 
stream from its peer, operates on the RSVP signals as an RSVP- 
configured router, and forwards the received IP datagrams (including 
the updated PATH signals) into its enclave. The PATH signals 
originated by H1, H2, and H3 are therefore forwarded towards H4, H5, 
and H6 according to the routing of the enclave. 


H4, H5, and H6 now receive the original PATH signals and deliver them 
to their application. 


2.3.2. Initial Routine Reservations - Request Reservation 


The application in H4, H5, and H6 decides to install the indicated 
reservations, meaning that they now reply with RESV signals. These 
signals request the bandwidth reservation. Following the trail left 
by the PATH signals, the RESV signals traipse back to their 
respective sources. The state left by the PATH signals leads them to 
VPN4, VPN5, and VPN6, respectively. If the routers in the enclaves 
are configured for RSVP, this will be explicitly via R4, R5, or R6; 
if they are not, routing will lead them through those routers. 


The various RSVP-configured routers en route in the enclave 
(including the VPN router on the "enclave" side) will verify that 
there is sufficient bandwidth on their links and that any other 
stated policy is also met. Having accomplished that, each will 
update its reservation state and forward the RESV signal to the next. 
The VPN routers will also each generate an RESV for the reservation 
within the interface domain, attempting to set or increase the 
bandwidth of the reservation appropriately. 


The various RSVP-configured routers en route in the interface domain 
(including VPN8) will verify that there is sufficient bandwidth on 
their links and that any other stated policy is also met. Having 
accomplished that, each will update its reservation state and forward 
the RESV signal to the next. VPN8 will also generate an RESV for the 
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reservation within the inner domain, attempting to set or increase 
the bandwidth of the reservation appropriately. This gets the 
reservation to the inner deaggregator, VPN8. 


The various RSVP-configured routers en route in the inner domain 
(including VPN7) will verify that there is sufficient bandwidth on 
their links and that any other stated policy is also met. Having 
accomplished that, each will update its reservation state and forward 
the RESV signal to the next. This gets the signal to VPN7. 


VPN7 acts as an [RFC3175] aggregator for the inner domain. This 
means that it receives the RESV signal for the inner domain 
reservation and stores state, decrypts the data stream from VPN8, 
operates on the RSVP signals as an RSVP-configured router, and 
forwards the received IP datagrams (including the updated RESV 
signals) into its interface domain. The RESV signals originated by 
VPN4, VPN5, and VPN6 are therefore forwarded towards VPN1, VPN2, and 
VPN3 through the interface domain. 


VPN1, VPN2, and VPN3 each act as an [RFC3175] aggregator for the 
interface domain. This means that it receives the RESV signal for 
the interface domain reservation and stores state, decrypts the data 
stream from its peer, operates on the RSVP signals as an RSVP- 
configured router, and forwards the received IP datagrams (including 
the updated RESV signals) into its enclave. The RESV signals 
originated by H4, H5, and H6 are therefore forwarded towards H1, H2, 
and H3 according to the routing of the enclave. 


H1, H2, and H3 now receive the original RESV signals and deliver them 
to their application. 


2.3.3. Installation of a Reservation Using Precedence 


Without going through the details called out in Sections 2.3.1 and 
2.3.2, if sufficient bandwidth exists to support them, reservations 
of other precedence levels or other applications may also be 
installed across this network. If the "routine" reservations already 
described are for voice, for example, and sufficient bandwidth is 
available under the relevant policy, a reservation for voice at the 
"priority" precedence level might be installed. Due to the mechanics 
of preemption, however, this would not expand the existing "routine" 
reservations in the interface and inner domains, as doing this causes 
loss of information - how much of the reservation is now "routine" 
and how much is "priority"? Rather, this new reservation will open 
up a separate set of tunnels or security associations for traffic of 
its application class at its precedence between that aggregator and 
deaggregator. 
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As a side note, there is an opportunity here that does not exist in 
the PSTN. In the PSTN, all circuits are potentially usable by any 
PSTN application under a certain set of rules (H channels, such as 
those used by video streams, must be contiguous and ordered). As 
such, if a channel is not made available to routine traffic but is 
made available to priority traffic, the operator is potentially 
losing revenue on the reserved bandwidth and deserves remuneration. 
However, in the IP Internet, some bandwidth must be kept for basic 
functions such as routing, and, in general, policies will not permit 
100% of the bandwidth on an interface to be allocated to one 
application at one precedence. As a result, it may be acceptable to 
permit a certain portion (e.g., 50%) to be used by routine voice and 
a larger amount (e.g., 60%) to be used by voice at a higher 
precedence level. Under such a policy, a higher precedence 
reservation for voice might not result in the preemption of a routine 
call, but rather impact elastic traffic, and might be accepted at a 
time that a new reservation of lower precedence might be denied. 


In microwave networks, such as satellite or mobile ad hoc, one could 
also imagine network management intervention that could change the 
characteristics of the radio signal to increase the bandwidth under 
some appropriate policy. 


2.3.4. Installation of a Reservation Using Preemption 


So we now have a number of reservations across the network described 
in Figure 5 including several reservations at "routine" precedence 
and one at "priority" precedence. For sake of argument, let us 
presume that the link from VPN7 to R9 is now fully utilized - all of 
the bandwidth allocated by policy to voice at the routine or priority 
level has been reserved. Let us further imagine that a new 
"priority" reservation is now placed from H3 to H6. 


The process described in Section 2.3.1 is followed, resulting in PATH 
state across the network for the new reservation. This is installed 
even though it is not possible to install a new reservation on VPN7- 
R9, as it does not install any reservation and the network does not 
know whether H6 will ultimately require a reservation. 


The process described in Section 2.3.2 is also followed. The 
application in H6 decides to install the indicated reservation, 
meaning that it now replies with an RESV signal. Following the trail 
left by the PATH signal, the RESV signal traipses back towards H3. 
VPN6 and (if RSVP was configured) R6 verify that there is sufficient 
bandwidth on their links and that any other stated policy is also 
met. Having accomplished that, each will update its reservation 
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state and forward the RESV signal to the next. VPN6 also generates 
an RESV for the reservation within the interface domain, attempting 
to set or increase the bandwidth of the reservation appropriately. 


VPN6, R8, and VPN8’s "interface domain" sides now verify that there 
is sufficient bandwidth on their links and that any other stated 
policy is also met. Having accomplished that, each will update its 
reservation state and forward the RESV signal to the next. VPN8 will 
also generate an RESV for the reservation within the inner domain, 
attempting to set or increase the bandwidth of the reservation 
appropriately. This gets the reservation to the inner deaggregator, 
VPN8. 


VPN8’s "inner domain" side and R9 now verify that there is sufficient 
bandwidth on their links and that any other stated policy is also 
met. At R9, a problem is detected - there is not sufficient 


bandwidth under the relevant policy. In the absence of precedence, 
R9 would now return an RESV Error indicating that the reservation 
could not be increased or installed. In such a case, if a 


preexisting reservation of lower bandwidth already existed, the 
previous reservation would remain in place but the new bandwidth 
would not be granted, and the originator (H6) would be informed. Let 
us clarify what it means to be at a stated precedence: it means that 
the POLICY_DATA object in the RESV contains a Preemption Priority and 
a Defending Priority with values specified in some memo. With 
precedence, [RFC4495]’s algorithm would have the Preemption Priority 
of the new reservation compared to the Defending Priority of extant 
reservations in the router, of which there are two: one VPN7->VPN8 at 
"routine" precedence and one VPN7->VPN8 at "priority" precedence. 
Since the Defending Priority of routine reservation is less than the 
Preemption Priority of a "priority" reservation, the "routine" 
reservation is selected. R9 determines that it will accept the 
increase in its "priority" reservation VPN7->VPN8 and reduce the 
corresponding "routine" reservation. Two processes now occur in 
parallel: 


o The routine reservation is reduced following the algorithms in 
[RFC4495] and 


o The priority reservation continues according to the usual rules. 


R9 reduces its "routine" reservation by sending an RESV Error 
updating its internal state to reflect the reduced reservation and 
sending an RESV Error to VPN8 requesting that it reduce its 
reservation to a number less than or equal to the relevant threshold 
less the sum of the competing reservations. VPN8, acting as a 
deaggregator, makes two changes. On the "inner domain" side, it 
marks its reservation down to the indicated rate (the most it is now 
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permitted to reserve), so that if an RESV Refresh event happens, it 
will request the specified rate. On the "interface domain" side, it 
selects one or more of the relevant reservations by an algorithm of 
its choosing and requests that it likewise reduce its rate. For the 
sake of argument, let us imagine that the selected reservation is the 
one to VPN5. The RESV Error now makes its way through R8 to VPN5, 
which similarly reduces its bandwidth request to the stated amount 
and passes a RESV Error signal on the "enclave" side requesting that 
the reservation be appropriately reduced. 


H5 is now faced with a decision. If the request is to reduce its 
reservation to zero, that is equivalent to tearing down the 
reservation. In this simple case, it sends an RESV Tear to tear down 
the reservation entirely and advises its application to adjust its 
expectations of the session accordingly, which may mean shutting down 
the session. If the request is to reduce it below a certain value, 
however, it may be possible for the application to do so and remain 
viable. For example, if a VoIP application using a G.711 codec (80 
kbps) is asked to reduce its bandwidth below 70 kbps, it may be 
possible to renegotiate the codec in use to G.729 or some other 
codec. In such a case, the originating application should re-reserve 
at the stated bandwidth (in this case, 70 kbps), initiate the 
application level change, and let the application change the 
reservation again (perhaps to 60 kbps) when it has completed that 
process. 


At the time the reservation is being processed at R9, for the 
"priority" reservation, R9 believes that it has sufficient bandwidth 
and that any other stated policy is also met, and it forwards the 
RESV to VPN7. Each will update its reservation state and forward the 
RESV signal to the next. VPN7 now acts as an [RFC3175] aggregator 
for the inner domain. This means that it receives the RESV signal 
for the inner domain reservation and stores state, decrypts the data 
stream from VPN8, operates on the RSVP signals as an RSVP-configured 
router, and forwards the received IP datagrams (including the updated 
RESV signals) into its interface domain. The RESV signals originated 
by VPN4, VPN5, and VPN6 are therefore forwarded towards VPN1, VPN2, 
and VPN3 through the interface domain. 


VPN3 now acts as an [RFC3175] aggregator for the interface domain. 
This means that it receives the RESV signal for the interface domain 
reservation and stores state, decrypts the data stream from its peer, 
operates on the RSVP signals as an RSVP-configured router, and 
forwards the received IP datagrams (including the updated RESV 
signals) into its enclave. The RESV signal originated by H6 is 
therefore forwarded towards H3 according to the routing of the 
enclave. 
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H3 now receives the original RESV signals and delivers it to the 
relevant application. 


This section details the data flows within a VPN router, 
It specifically 


identifies the signaling flow at a given VPN boundary and 
additionally elaborates the signaling mechanism with the aid of a 
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Parameters on a reservation include: 


Destination Address: On the plaintext side, the VPN router 
participates in the end-to-end reservations being installed for 
plaintext sessions. These may include individual flows as 
described in [RFC2205], IPsec data flows [RFC2207], aggregate 
reservations [RFC3175], or other types. It passes an identifier 
for the ciphertext side of the deaggregator to its ciphertext 
unit. 


DSCP: The DSCP of the plaintext data flow is provided to the cipher 
text side. 


Virtual Port: The virtual destination port is provided to the cipher 
text side. This may be derived from an [RFC2207] session object 
or from policy information. 


Mean Rate: The sum of the plaintext mean rates is provided to the 
ciphertext unit. 


Peak Rate: A function of the plaintext peak rates is provided to the 
ciphertext unit. This function is less than or equal to the sum 
of the peak rates. 


Burst Size: The sum of the burst sizes is provided to the cipher 
text unit. 


Messages include: 


Path: The plaintext PATH message is sent as encrypted data to the 
ciphertext unit. In parallel, a trigger needs to be sent to the 
ciphertext unit that results in it generating the corresponding 
aggregated PATH message for the ciphertext side. 


Path Error: This indicates that a PATH message sent to the remote 
enclave was in error. In the error case, the message itself is 
sent on as encrypted data, but a signal is sent to the ciphertext 
side in case the error affects the ciphertext reservation (such as 
removing or changing state). 


Path Tear: The PATH Tear message is sent as encrypted data to the 
ciphertext unit. In parallel, a signal is sent to the cipher text 
Side; it will trigger a Path Tear on its reservation in the event 
that this is the last aggregated session, or change the 
SENDER_TSPEC of the aggregated session. 
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RESV: The plaintext RESV message is sent as encrypted data to the 
ciphertext unit. In parallel, a trigger needs to be sent to the 
ciphertext unit that results in it generating the corresponding 
aggregated RESV message for the ciphertext side. 


RESV Error: This indicates that a RESV message that was received as 
data and forwarded into the enclave was in error or needed to be 
preempted as described in [RFC3181] or [RFC4495]. In the error 
case, the message itself is sent on as encrypted data, but a 
signal is sent to the ciphertext side in case the error affects 
the ciphertext reservation (such as removing or changing state). 


RESV Tear: The RESV Tear message is sent as encrypted data to the 
ciphertext unit. In parallel, a signal is sent to the cipher text 
side; it will trigger a RESV Tear on its reservation in the event 
that this is the last aggregated session, or reduce the bandwidth 
of an existing reservation. 


RESV Confirm: This indicates that a RESV message received as data 
and forwarded into the enclave, and is now being confirmed. This 
message is sent as encrypted data to the ciphertext side, and, in 
parallel, a signal is sent to potentially trigger an RESV Confirm 
on the aggregate reservation. 
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Figure 7: Data Flows in a VPN Router Inbound 

The aggregate reservation is terminated by the ciphertext side of the 
VPN router. The RSVP messages related to the subsidiary sessions are 
carried in the encrypted tunnel as data, and therefore arrive at the 
plaintext side with other data. As the plaintext side participates 
in these reservations, some information is returned to the ciphertext 
size to parameterize the aggregate reservation as described in 
Section 3.1.1 in the processing of the outbound messages. 
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3.2. VPN Routers That Use the Network Guard for Signaling across the 
Cryptographic Boundary 


As described in Section 1.6 the Network Guard provides an additional 
path for the reservation signaling between the plaintext and cipher 
text domains. 
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Figure 8: RSVP Passage via Network Guard 


In this context, the VPN router is composed of a plaintext router, a 
ciphertext router, an encrypt/decrypt implementation (such as a line 
card or interface device), and a network management process that 
manages the encrypt/decrypt implementation and potentially passes 
defined information flows between the plaintext and ciphertext 
domains. If the Network Guard is implemented as a software process 
that exchanges configuration instructions between the routers, this 
is simple to understand. If it is built as a separate systems 
exchanging datagrams, it is somewhat more complex, but conceptually 
equivalent. For example, the ciphertext router would consider an IP 
datagram received via the Network Guard (control plane) as having 
been received from and concerning the interface used in the data 
plane to the encrypt/decrypt unit. 
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3.2.1. Signaling Flow 


Encrypt/decrypt units may not be capable of terminating and 
originating flows as described in Section 3.1, and policy may prevent 
knowledge of the ciphertext network addresses in the plaintext 
router. In such a case, the plaintext and ciphertext routers may use 
the Network Guard as the path for the signaling flows. The Network 
Guard performs the following functions to enable the flow of 
reservation signaling across the cryptographic domain 


o transforms plaintext session identifiers into ciphertext session 
identifiers and vice-versa in IP datagrams and RSVP objects (e.g. 
IP addresses) 


o performs resource management of aggregated reservations (e.g., 
including ciphertext encapsulation overhead to resources 
requested) 


o reads and writes configuration on the encrypt/decrypt units as 
necessary (e.g., reads plaintext to ciphertext IP address mapping) 


In addition, the plaintext and ciphertext routers must support a 
routing function or local interface that ensures that aggregated RSVP 
messages flow via the Network Guard. However, the signaling flow 
across the entire VPN router at a cryptographic boundary remains 
identical to the description in Section 3.1. 


A reader may note that the VPN router described in Figure 8 can be 
collapsed into a single router with two halves, or the Network Guard 
and the encrypt/decrypt units can be part of the plaintext router. 
The details of alternate logical and physical architectures for the 
VPN router are beyond the scope of this document. 
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3.2.2. Use Case with Network Guard 
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Figure 9: Aggregated RSVP via Network Guard 


The above figure depicts a simple use case for aggregated signaling 
with the Network Guard. In this scenario, Host A initiates RSVP 
signaling to Host B for a reservation. The RSVP signaling between 
the hosts is encapsulated by the VPN routers into encrypted tunnels. 
Aggregated RSVP signaling is triggered by VPN routers, and flows into 
the CT-Routers, as well as the interface domains, to reserve 
resources at RSVP-capable routers on the path. The aggregation/ 
deaggregation point for RSVP reservations in this use case are the 
PT-Routers. The signaling aggregation of RSVP into A-RSVP at the 
PT-Router is similar to the data flow described in Section 3.1. The 
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Network Guard performs the additional functions described in Section 
3.2.1 to transform plaintext A-RSVP messages into suitable ciphertext 
A-RSVP messages. A typical reservation set up in this case would 
follow these steps. 


o Host A sends RSVP PATH message to Host B. 


o PT-Router-A encapsulates RSVP PATH message in encrypted tunnel to 
VPN Router B. 


o CT Routers and Interface domain carry encrypted RSVP PATH message 
(like any other encrypted data message). 


o PT-Router-B decrypts RSVP Path Message and sends an E2E PathErr 
message to PT-Router-A in the encrypted tunnel. 


o PT-Router-B forwards decrypted plaintext RSVP PATH message to Host 
B. 


o PT-Router-A receives E2E PathErr and sends an aggregated RSVP PATH 
message towards PT-Router-B via the Network Guard. 


o The NetGrd-A transforms the plaintext aggregate RSVP into the 
ciphertext aggregate RSVP message as described in Section 3.2.1 
and sends it to the CT-Router-A. 


o The ciphertext aggregated RSVP message travels through ciphertext 
routers in the interface domain. 


o CT-Router-B receives the ciphertext aggregate RSVP message and 
sends it to the NetGrd-B. 


o The NetGrd-B transforms the ciphertext aggregate RSVP into the 
plaintext aggregate RSVP message as described in Section 3.2.1 and 
sends it to the PT-Router-B. 


The subsequent RSVP and Aggregate RSVP signaling follows a similar 
flow, as described in detail in [RFC3175] and [RFC4860]to aggregate 
each plaintext reservation into a corresponding ciphertext 
reservation. This ensures that RSVP-capable ciphertext routers 
reserve the required resources for a plaintext end-to-end 
reservation. Subsequent mechanisms, such as preemption or the 
increase and decrease of resources reserved, may be applied to these 
reservations as described before in this document. The RSVP data 
flow as described in Section 3.1 within the VPN router (from the 
plaintext router to the ciphertext router via the Guard) provides 
necessary and sufficient information to routers in the ciphertext 
domain to implement the QoS solution presented in the document. 
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In this description, we have described the Network Guard as being 
separate from the encrypt/decrypt unit. This separation exists 
because in certain implementations, it is mandated by those who 
specify the devices. The separation does not come for free, however; 
the separation of the devices for system-engineering purposes is 
expensive, and it imposes architectural problems. For example, when 
the Guard is used to aggregate RSVP messages or Protocol Independent 
Multicast (PIM) routing, the traffic is destined to the remote VPN 
router. This means that the Guard must somehow receive and respond 
to, on behalf of the VPN Router, messages that are not directed to 


it. Several possible solutions exist; they should be selected 
carefully based on the security and implementation needs of the 
environment. They are as follows: 


o In the simplest case, the Network Guard and encrypt/decrypt unit 
can be two independent functions that utilize a common network and 
MAC layer. This can allow the two functions to share a common MAC 
and IP address, so that traffic destined for one function is also 
received by the other. In the case that these two functions are 
physically separated on two devices, they can still share a common 
MAC and IP address; however, additional modifications may be 
required on the Guard to filter and not process IP traffic not 
destined for itself. 


o The ciphertext interface of the Guard could be placed into 
promiscuous mode, allowing it to receive all messages and discard 
all but the few it is interested in. The security considerations 
on putting a device in promiscuous mode at the VPN boundary needs 
to be taken into account in this method. 


o The Guard could be engineered to receive all from the ciphertext 
router and pass the bulk of it on to the VPN router through 
another interface. In this case, the Guard and the VPN router 
would use the same IP address. This mechanism puts the load of 
all data and management traffic destined for the VPN router upon 
the Guard. 


o The VPN router could be engineered to receive all traffic from the 
ciphertext router and pass any unencrypted traffic it receives to 
the Guard through another interface. In this case, the Guard and 
the VPN router would use the same IP address. 


o All the VPN router functions, as shown in Figure 9, could be 
incorporated into a single chassis, with appropriate internal 
traffic management to send some traffic into the plaintext enclave 
and some to the Guard. In this case, the Guard and the VPN router 
would be -- at least, functionally -- the same system. 
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Of these, clearly the last is the simplest architecturally and the 
one that most minimizes the attendant risk. 


4. Security Considerations 


The typical security concerns of datagram integrity, node and user 
authentication are implicitly met by the security association that 
exists between the VPN routers. The secure data stream that flows 
between the VPN routers is also used for the reservation signaling 
datagrams flowing between VPN routers. Information that is contained 
in these signaling datagrams receives the same level of encryption 
that is received by the data streams. 


One of the reasons cited for the nesting of VPN routes in Section 1.3 
is the different levels of security across the nested VPN routers. 

If the security level decreases from one VPN router to the next VPN 
Router in the nested path, the reservation signaling datagrams will, 
by default, receive the lower security-level treatment. For most 
cases, the lower security treatment is acceptable. In certain 
networks, however, the reservation signaling across the entire nested 
path must receive the highest security-level treatment (e.g., 
encryption, authentication of signaling nodes). For example, the 
highest precedence level may only be signaled to VPN routers that can 
provide the highest security levels. If any VPN router in the nested 
path is incapable of providing the highest security level, it cannot 
participate in the reservation mechanism. 


In the general case, the nested path may contain routers that are 
either incapable of participating in VPNs or providing required 
security levels. These routers can participate in the reservation 
only if the lower security level is acceptable (as configured by 
policy) for the signaling of reservation datagrams. 


VPN routers encapsulate encrypted IP packets and prepend an extra 
header on each packet. These packets, whether used for signaling or 
data, should be identifiable, at a minimum by the IP addresses and 
DSCP value. Therefore, the prepended header should contain, at a 
minimum, the DSCP value corresponding to the signaled reservation in 
each packet. This may literally be the same DSCP as is used for the 
data (forcing control plane traffic to receive the same QoS treatment 
as its data), or a different DSCP that is routed identically 
(separating control and data-plane traffic QoS but not routing). 


Additionally security considerations as described in [RFC4860] and 
[RFC3175] are also applicable in this environment; they include the 
integrity of RSVP messages can be ensured via mechanisms described in 
[RFC2747] and [RFC3097] and related key management (through manual 
configuration or a key management protocol) at nodes between any 
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6. 


6. 


aggregator and deaggregator pair that processes the messages. In 
addition, confidentiality can be provided between hops by employing 
IPsec. Further work in the IETF MSEC Working Group may be applicable 
in these environments for key management and confidentiality. 
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